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Abstract 

The  concurrency  control  lock  (e.g.  file  lock,  table  lock)  has  long  been  used  as  a 
canonical  exampleof  a  covert  channel  in  a  database  system.  Locking  is  a  funda¬ 
mental  concurrency  control  technique  used  in  many  kinds  of  computer  systems 
besides  database  systems. Locking  is  generally  considered  to  be  interfering  and 
hence  unsuitablefor  multilevel  systems.  In  this  paper  we  show  how  such  locks 
can  be  used  for  concurrency  control,  without  introducing  covert  channels. 

1.  Introduction 

A  database  system  is  a  software  system  that  provides  a  collection  of  predefined 
operations  with  three  features:  1)  efficient  management  of  large  amounts  of  per¬ 
sistent  data  (the  database),  2)  transaction  management  for  transactions  com¬ 
posed  of  those  operations  on  the  data  (concurrency  control,  atomicity,  and 
recovery  from  failure),  and  3)  a  data  model  that  provides  a  simple  abstraction  for 
understanding  how  the  predefined  operations  and  data  interact.  Our  concern  is 
with  the  second  of  these  features,  transaction  management. 

Transaction  management  for  conventional  centralized  database  systems  is 
fairly  well  understood  and  much  progress  is  being  made  for  distributed  and  feder¬ 
ated  database  systems  [18].  Our  concern  is  with  transaction  management  in  what 
we  call  multilevel  database  systems  (which  may  also  be  centralized,  distributed, 
federated,  etc.).  Multilevel  database  systems  assign  their  data  to  security  classes 
and  restrict  database  operations  based  on  those  classes  [7].  The  security  classes 
are  partially  ordered;  the  data  and  operations  are  considered  to  be  in  various  lev¬ 
els,  hence  the  term  multilevel. 

A  database  system  that  just  provides  security  cl  asses  and  restrictions  on  oper¬ 
ations  is  not  multilevel.  An  additional  feature  of  multilevel  database  systems  is 
their  ability  to  enforce  the  cl  asses  and  restrictions  in  thefaceof  nontrivial  at¬ 
tempts  to  bypass  or  tamper  with  the  enforcement  mechanisms.  One  of  the  most 
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difficult  challenges  for  multilevel  databases  is  the  covert  channel  problem.  A  da¬ 
tabase  system  user  with  "low"  privileges  can  obtain  information  from  "higher"  se¬ 
curity  classes  by  having  it  leaked  into  his  or  her  security  class  from  the  higher 
classes,  by  a  Trojan  horse  or  virus,  via  a  covert  channel.  A  covert  channel  is  a 
means  of  unauthorized  interprocess  communication  that  uses  a  mechanism  not 
intended  for  interprocess  communication. 

The  concurrency  control  lock  (e.g.  file  lock,  table  lock)  has  long  been  used  as  a 
canonical  example  of  a  covert  channel  in  a  database  system.  Locking  is  a  funda¬ 
mental  concurrency  control  technique  used  in  many  kinds  of  computer  systems 
besides  database  systems.  Locking  is  generally  considered  to  be  interfering,  in 
the  sense  of  [6,16],  and  hence  unsuitable  for  multilevel  systems. 

I  n  this  paper  we  show  how  locks  can  be  used  for  concurrency  control,  without 
introducing  covert  channels.  We  have  developed  three  locking  algorithms  that  do 
not  introduce  signal  ling  channels1  yet  they  produce  serializable  transaction  his¬ 
tories.  Early  work  on  concurrency  control  for  multi  level -secure  data  base  systems 
was  done  by  Hinkeand  Schaefer,  where  quasi-synchronization  [8]  was  used  to 
solve  the  secure  readers  and  writers  problem,  without  channels.  Quasi -synchro¬ 
nized  histories  are  not  necessarily  serializable  (not  surprisingly,  since  Hinkeand 
Schaefer's  work  was  coeval  with  the  development  of  seri alizabi  I  ity  theory  [5].) 
Reed  and  Kanodia  later  developed  a  general  mechanism  [17]  for  solving  problems 
similar  to  the  secure  readers  and  writers  problem,  but  it  too  is  unable  to  guaran¬ 
tee  seri  alizabi  I  ity.  Previous  algorithms  that  do  produce  serializable  histories  for 
concurrency  control,  without  channels,  have  relied  on  timestamping  [1,10,11]  or 
are  based  on  subtle  properties  of  a  particular  database  system  architecture 
[3,9,14],  Our  orange  locking  algorithms  do  not  usetimestamps  and  they  do  not 
depend  on  the  underlying  architecture  of  the  database  system.  The  rest  of  this 
paper  is  organized  as  follows.  First,  we  discuss  transactions,  conventional  lock¬ 
ing,  and  covert  channels.  Then  we  present  three  locking  algorithms:  conservative 
orange  locking,  reset  orange  locking,  and  optimistic  orange  locking.  We  show 
these  algorithms  to  be  correct  (serializable)  and  secure  (non interfering),  and  dis¬ 
cuss  their  deadlock  properties.  Finally,  because  of  our  own  interest  in  the  repli¬ 
cated  architecture,  we  show  how  orange  locking  can  be  used  to  implement 
immediate-write  algorithms  for  the  replicated  architecture. 

2.  Transaction  Management  in  Multilevel  Databases 

A  transaction  is  an  abstract  unit  of  concurrent  computation  that  executes 
atomically.  The  effects  of  a  transaction  do  not  interfere  with  other  transactions 
that  access  the  same  data.  Also,  a  transaction  either  happens  with  all  of  its  ef¬ 
fects  made  permanent  or  it  doesn't  happen  and  none  of  its  effects  are  permanent. 
A  useful  model  of  a  transaction  must  show  how  these  properties  can  be  achieved 
by  composing  smaller  units  of  computation,  when  those  smaller  units  are  not  nec¬ 
essarily  guaranteed  to  compose  into  an  atomic  transaction.  Thus  the  model  must 


1.  Wedistinguish  implementation  invariant  (i.e.  inherent  in  the  algorithm  itself)  covert  channels 
as  signalling  channels.  An  implementation  of  a  signalling-channel  free  algorithm  may  still  have 
covert  channels. 


be  concerned  with  showing  potential  conflicts  between  operations  and  with  show¬ 
ing  arbitrary  orderings.  Since  we  are  managing  transactions  for  secure  database 
systems,  our  model  must  also  reflect  the  security  policy  enforced  by  the  DBS  [13]. 

I  n  this  report  we  model  transactions  as  sequences  of  abstract  read,  readjock, 
read_unlock,  write,  writejock,  write_unlock,  commit,  and  abort  operations,  de¬ 
noted  r[x],  rl[x],  ru[x],  w[x],  wl[x],  wu[x],  c,  and  a,  respectively  The  sequence  mod¬ 
els  the  order  in  which  database  operations  are  sent  to  the  transaction 
management  algorithms,  without  modeling  the  control  structure  of  transactions 
themselves.Modeling  transactions  as  sequences  is  desirable  because  the  sequenc¬ 
es  can  be  used  in  a  noninterference  [6,16]  or  restrictiveness  [12]  model  to  reason 
about  the  security  of  our  algorithms. 

Definition  1.  A  databaseD  is  afiniteset  of  pairwisedisjoint  data  items  that  can  be 
operated  on  by  a  single  atomic  data  base  operation.  Each  data  item  x  in  D  has  a 
countable  domain  dom(x).  A  data  base  state  is  an  element  of  the  Cartesian  product 
of  the  domains  of  elements  of  D,  that  is,  a  state  associ ates  a  value  with  each  data 
item  in  the  database.  The  integrity  constraints  on  a  database  specify  a  subset  of 
the  Cartesian  product,  that  is,  the  consistent  database  states.  A  transaction  state 
of  a  transaction  is  an  element  of  the  Cartesian  product  of  thedomains  of  thetrans- 
action's  basis  set.  A  transaction  state  associ  ates  a  value  with  each  data  item  that 
is  read  or  written  by  the  transaction.  A  database  system  state,  or  DBS  state,  on  a 
history/-/  is  a  tuplecontaining  a  database  state  as  its  first  element  and  a  transac¬ 
tion  statefor  every  transaction  in  history/-/.  Each  database  operation  maps  a  DBS 
state  to  a  D  B  S  state.  □ 

Definition  2.  A  transaction  T  is  a  finite  sequence  of  database  operations  from  some 
finite  set  O.  Usually  O  ={  r[» ],  rl[» ],  ru[* ],  w[* ],  wl[* ],  wu[» ],  c,  a}  .  We  will  take 
this  read-write  model  as  our  definition  unless  we  say  otherwise.  We  denote  single 
operations  as  one-element  sequences  thus  r[x].  Concatenation  of  sequences  is  de¬ 
noted  by  juxtaposition.  If  transaction  T  reads  x,  then  writesxand  commits  wecan 
denote  transaction  T  as  the  sequence  r[x]w[x]cT.  Wecan  also  show  a  transaction 
as  a  concatenation  of  unspecified  sequences  of  database  operations,  likeT  =  a  r/x/p. 
We  will  always  use  lower  case  Greek  letters  to  indicate  subsequences  of  database 
operations. We  use  X  to  denote  the  empty  sequence. 

If  a  sequence  of  database  operations  is  a  transaction,  we  further  requirethat  if 
the  transaction  T=ap,  that  is,  the  sequence  of  operations  a  followed  the  singleton 
sequence p,  then  p  must  be  either  Cj  or  aj  and  also  that  neither  Cj  nor  aj  be  in 
a .  □ 

Definition  3.  Let  S2  be  a  sequence  that  contains  only  distinct  elements  and  let  S2 
bea  sequence  that  contains  only  distinct  elements.  Say  that  these  two  sequences 
are  compatible  if  they  do  not  contain  inconsistent  orderings  of  elements  common 
toS2  and  S2.  For  example,  if  a,  beS1  and  a,  be  S2and  if  Sj  orders  a  and  b  as  a<b 
and  S2  orders  a  and  b  as  ixa,  then  S2  and  S2  are  not  compatible  sequences.  Let 
imageSi  denote  the  set  of  elements  in  sequences^.  Defi  ne  the  shuffle  of  two  com¬ 
patible  sequences  S2  andS2,  denoted  S2*S2,  to  be  the  set  of  all  sequences  that  con¬ 
tain  just  the  elements  of  (imageSj)  u(imageS2)  andcontainS2  andS2as 
subsequences.  The  extension  totheshuffleS2*S2*...*S^of  morethan  twocompat- 


ible  sequences  is  straightforward.  □ 

Definition  4.  A  history  H  over  a  set  of  transactions  T={T1,  T  2,  ...  Jk\  is  an  ele¬ 
ment  of  the  shuffle  of  T,  that  is  H  is  a  sequence  in  Tj*T2*...  *7^.  A  serial  history 
has  every  operation  of  transaction  7/  before  every  operation  of  transaction  Tj  (or 
vice  versa),  for  every  pair  of  transactions  (7/,  Tj)  in  H .  □ 

Definition  5.  We  define  two  operations  p[x]  and  q[x]  to  conflict  if  one  of  them  is  a 
write  oper at i  on .  I  nt u  i  t i  vel  y  confl  icti  ng  oper at i  on s  do  n ot  commute;  we  get  d i  ffer ent 
results  if  conflicting  operations  p  and  pare  done  in  different  orders.  We  say  that 
two  transactions  conflict  if  they  contain  conflicting  operations.  □ 

We  can  now  define  conflict  equivalence  using  the  notion  of  conflicting  opera¬ 
tions. 

Definition  6.  Two  histories  /-/^  and  H2  are  (conflict)  equivalent  if 

1.  they  are  defined  over  the  same  set  of  transactions  and  operations, 

2.  for  any  pair  of  conflicting  operations  Pj[x],  qj[x],  (i  not  necessarily  distinct 
from  j)  such  that  a,,  aj  are  not  in  Hlr  we  have/-/2=aip//x/piq//x/yi  iff 

H  2=  a  2Pj  [x]  p  2qj  [x]y 2 .  □ 

In  this  discussion  we  take  the  view  that  histories  are  correct  if  they  are  serial¬ 
izable,  that  is,  equivalent  to  some  serial  history.  Because  aborted  transactions 
have  no  permanent  effect  on  the  database  state  we  do  not  include  them  in  our 
equivalent  serial  histories.  Because  active  transactions  (i.e.  those  that  have  not 
committed  or  aborted  yet)  may  abort,  we  do  not  include  them  either.  Toaccommo- 
datethis  in  our  equivalence  we  define  the  committed  projection  C(H)  of  a  history 
H  to  be  the  history  obtained  from  H  by  removing  operations  that  belong  to  un¬ 
committed  transactions. 

Definition  7.  Formally,  we  say  that  history/-/  is  serializableif  its  committed  projec¬ 
tion  C(H)  is  equivalent  to  some  serial  history.  □ 

Definition  8.  A  serialization  order  of  a  history  H  is  the  order  that  transactions  ap¬ 
pear  in  a  serial  history  that  is  equivalent  to  the  committed  projection  of  history/-/. 
A  serial  history  equivalent  to  the  committed  projection  of  H  is  not  necessarily 
uniqueso/-/  may  have  several  serialization  orders.  □ 

Definition  9.  To  model  the  security  pol i cy  enforced  by  our  database  systems  we  in¬ 
troduce  a  finite  set  of  subjects  S,  and  a  finite  lattice  (SC,  <)  of  security  classes.  The 
data  items  in  D  of  our  transaction  model  will  be  the  passive  entities  of  our  security 
model,  that  is,  abstract  units  of  protected  computer  resources.  A  subject  is  an  ab¬ 
stract  unit  of  secure  computation.  We  relate  subjects  to  transactions  by  defining  a 
subject  to  be  a  sequence  of  database  operations.  A  subject  may  or  may  not  be  a 
transaction.  Every  transaction  will  bea  sequence  of  one  or  moresubjectsand  every 
subject  in  our  security  model  will  be  in  oneand  only  one  transaction.  We  may  use 
the  terms  higher  and  lower  to  refer  to  a  relation  between  two  or  more  security 
classes.  By  higher,  we  mean  strictly  greater  than  and  by  lower  we  mean  strictly 
less  than.  We  use  a  mapping  X;DuS^>SC  to  give  the  security  class  of  every  data 


element  and  every  transaction. 

The  algorithms  we  present  here  apply  to  database  systems  that  enforce  the  fol¬ 
lowing  security  policy: 

1.  All  transactions  are  single-level.  That  is,  every  subject  in  a  transaction  has 
the  same  security  class  and  we  can  meaningfully  apply  our  level  function  to 
transactions,  thus  X  (T). 

2.  Subject  S  is  not  allowed  to  read  data  element  xe  D  unless  X(S)>X  (x). 

3.  Subject  S  is  not  allowed  to  write  into  data  element  xeD  unless  X  (S)=X(x) . 

4.  X  (S)  and  X  (x)  do  not  change.  □ 

Definition  10.  If  two  transactions  7/  and  Tj  have  security  classes  X  (Tj),  X  (Tj)  such 
that  X  (T j)<  X  (Tj),  then  Tj  and  Tj  are  low  and  high  transactions  with  respect  to  each 
other.  We  introduce  this  definition  simply  for  convenience  of  exposition.  □ 

Definition  11.  A  transaction  Tj  reads x  from  transaction  Tj  in  history  H  if 
H=  a  wj[x]$  r,[x] y 

and  aj€  (3  and  if  w^[x]e  (3  then  a (3 .  □ 

Definition  12.  A  read-down  is  a  read  operation  r[x]  of  a  transaction  Tj  such  that 
X  (Tj)>  X  (x).  Data  item  x  i  s  a  read-down  data  i tern.  I  f  transacti on  Tj  reads  x  from 
transaction  Tj  and  x  is  a  read-down  data  item,  then  Tj  reads-x-down  from  Tj,  and 
if  for  some  data  item  x,  Tj  reads-x-down  from  Tj,  then  Tj  reads-down  from  Tj.  □ 

3.  Locking  and  Channels 

Concurrency  control  via  conventional  locking  is  based  on  the  following  princi¬ 
ple:  1)  each  operation  that  isto  be  scheduled  includes  a  (possibly  implicit)  lock  re¬ 
quest,  and  2)  if  a  transaction  requests  a  lock  pljfx]  that  conflicts  with  a  lock  qljfy] 
that  is  already  set  then  the  requesting  transaction  is  delayed.  Two  locks  pljfx]  and 
qljfy]  conflict  if  their  corresponding  operations  p  and  q  conflict,  x=y,  and  /Vy. 
Locks  can  be  implemented  as  a  lock  table  inside  the  scheduler.  Our  abstract  read 
lock  rljfx]  is  implemented  as  a  lock  table  entry  or,  read,  />.  Transactions  that  are 
delayed  can  be  placed  on  a  queue  associated  with  the  entry;  the  mechanism  for  ef¬ 
fecting  the  del  ay  depends  on  the  underlying  operating  system.  The  setting  and  re¬ 
leasing  of  locks  and  the  scheduling  of  operations  is  done  by  the  scheduler. 
Transactions  request  operations  and  the  scheduler  returns  the  results  when  they 
areavailabl  e. 

Intuitively,  locking  should  be  sufficient  by  itself  to  ensure  correct  database  sys¬ 
tem  operation.  Unfortunately,  it  is  not.  Locking  intended  toachieveserializability 
must  also  be  two-phase,  in  the  foil  owing  sense.  Transactions  that  use  two-phase 
locking  have  a  growing  phase  wherein  all  of  a  transaction's  locks  are  set  and  a 
shrinking  phase  wherein  all  of  its  locks  are  released.  A  transaction's  locks  are  not 
necessarily  set  or  released  all  at  the  same  time,  but  no  lock  may  beset  after  a  lock 
has  been  released.  Formally,  we  say  that  for  any  data  items  x and  y,  and  any 
transaction  Tj,  it  is  always  the  case  that  pljfx]  precedes  qujfy]. 


To  make  recovery  from  failures  tractable,  two-phase  locking  algorithms  are  of¬ 
ten  designed  to  b estrict.  A  transaction  scheduled  by  a  strict  two-phase  locking  al¬ 
gorithm  holds  all  of  its  write  locks  until  the  end  of  the  transaction,  and  then 
releases  them  together. 

Conventional  locking  introduces  a  signalling  channel.  If  a  virus  or  Trojan  horse 
in  transaction  7/  wishes  to  signal  information  to  a  less  privileged  transaction  Tj 
(i.e.  Tj  runs  in  a  lower  security  class)  it  can  do  so  by  reading  down,  from  some  pre¬ 
determined  data  item  x  such  that  the  security  class  of  x  is  the  same  as  Tj' s  securi¬ 
ty  class.  Transaction  T/'s  read  request  will  set  a  read  lock  rlj[x].  If  transaction  Tj 
now  tries  to  write  into  data  itemx,  transaction  Tj  will  be  delayed  by  the  read  lock 
rlj[x].  By  selectively  read  locking  and  read  unlocking  data  itemx,  transaction  Tj 
can  leak  information  to  Tj.  It  is  this  well-known  scenario  we  wish  to  prevent. 

4.  Optimistic  Orange  Locking  (OOL) 

Now  we  show  how  to  use  locks  for  concurrency  control,  in  a  way  that  does  not 
introduce  signal  ling  channels.  Our  first  algorithm  is  optimistic,  that  is,  opera¬ 
tions  are  never  delayed  by  the  scheduling  algorithm.  Instead,  when  a  transaction 
is  ready  to  commit,  the  scheduling  algorithm  checks  the  schedule  to  see  if  it  is 
correct.  If  not,  then  some  transaction  is  aborted  (to  be  rerun  later)  to  make  the 
schedule  correct. 

In  our  first  approach  we  simply  let  the  high  transaction  Tj  set  read  locks  on  low 
data  items  as  in  a  conventional,  untrusted  database  system.  If  a  low  transaction 
Tj  then  tries  to  set  a  write  lock  on  one  of  the  same  data  items,  we  immediately 
grant  T/'s  write  lock  and  change  7;  's  read-down  lock  to  an  orange  lock,  indicating 
the  possibility  of  an  incorrect  read 

Low  transactions  will  not  be  interfered  with  by  high  transactions  foil  owing  this 
approach.  However,  we  have  to  decide  what  to  do  with  high  transactions  that 
read  data  via  orange  locks  instead  of  read-down  locks.  If  we  simply  inform  the 
transactions  of  the  orange  locks  but  let  them  read  anyway,  the  transactions  will 
probably  be  incorrect.  The  read-down  operations  will  have  been  invalidated  by 
the  conflicting  write  that  was  performed  in  a  nonserial  izable  fashion. 

We  can  obtain  serial  izable  schedules  by  simply  aborting  a  transaction  whenev¬ 
er  its  first  read  down  is  orange  locked.  If  most  transactions  only  read  down  on  a 
few  data  items  and  transactions  are  easy  to  restart,  this  approach  will  allow  us  to 
correctly  schedule  them  in  a  simple  manner.  This  approach  begins  to  have  prob¬ 
lems  when  the  number  of  read-downs  increases  or  the  cost  of  restarting  a  trans¬ 
action  is  high.  We  can  do  better,  at  the  expense  of  an  increase  in  complexity,  by 
reducing  the  number  of  aborts  and  making  restarts  easier. 

First,  we  add  a  local  workspace  for  each  transaction.  The  local  workspace  con¬ 
tains  storage  for  all  the  values  a  transaction  will  read  down.  We  begin  each  trans¬ 
action  by  having  it  perform  all  of  its  read-downs  before  beginning  any  processing. 
After  all  of  the  data  items  in  the  local  workspace  are  read,  the  transaction  pro¬ 
ceeds  as  a  conventional  transaction,  reading  from  and  writing  to  the  database  di- 


rectly,  within  the  transaction's  security  class.  Any  read-downs  during  processing 
are  performed  from  the  transaction's  local  workspace. 

Definition  13.  A  transaction  7/  has  a  home- free  point  that  it  must  reach  beforecom- 
pleting  its  processing.  A  transaction  7/  has  reached  its  home-free  point  when  all 
data  items  xto  be  read  down  by  7/  are  either  read  locked  and  read  into 7,'s  local 
workspace  or  orange  locked  and  read  into  7/'s  local  workspace.  □ 

If  a  high  transaction  7/  reaches  its  home-free  point  without  any  orange  locks  it 
is  allowed  to  proceed.  If  7/  has  an  orange  lock  set  before  it  reaches  its  home  free 
point,  it  is  aborted.  This  abort  can  be  made  a  lightweight  abort,  that  is,  we  do  not 
need  to  resubmit  the  transaction  to  the  scheduler.  Instead  we  can  abort  by  releas¬ 
ing  all  read-down  locks,  resetting  the  local  workspace,  and  moving  the  transac¬ 
tion's  program  counter  back  to  the  beginning  of  the  transaction.  Thus  we  achieve 
the  effect  of  a  full  abort  with  less  overhead.  Because  we  do  all  our  read-downs  to¬ 
gether,  we  reduce  the  length  of  time  we  are  likely  to  be  interfered  with  bya  low 
transaction. 

Our  simple  optimistic  approach  can  be  shown  tobe  correct  becauseits  histories 
are  identical  to  histories  produced  by  conventional  two-phase  locking.  Transac¬ 
tions  that  do  not  conform  to  the  conventional  two-phase  model  are  aborted  and  do 
not  appear  in  the  committed  prefix  that  defines  the  current  stable  database  state. 
Our  workspace-based  improvement  is  also  correct;  we  will  show  how  later  in  this 
paper. 

The  advantage  of  thi  s  opti  mi  sti c  approach  i  s  that  we  have  a  rel  ati  vely  si  mpl  e 
algorithm,  even  with  our  workspace  version.  We  do  not  have  to  change  our  con¬ 
ventional  two-phase  locking  implementation  very  much.  Unfortunately,  we  get 
poor  performance  if  lock  contention  is  heavy  and  we  can  get  also  get  starvation  as 
a  high  transaction's  read-down  locks  are  repeatedly  set  to  orange,  forcing  the 
high  transaction  to  restart. 

Remark.  The  potential  for  infinite  overtaking  suggests  a  possibility  for  denial  of 
service.  Whilethis  is  theoretically  true,  it  is  of  no  practical  concern.  A  more  effec¬ 
tive  denial  of  servi ce  attack  can  be  mounted  with  crude  techniques  such  as  re¬ 
source  exhaustion. 

5.  Conservative  Orange  Locking  (COL) 

If  aborts  and  restarts  are  too  expensive,  but  we  sti  1 1  want  to  maintain  correct¬ 
ness  for  our  transactions,  we  can  do  so  by  using  a  conservative  approach.  Our  ap¬ 
proach  is  not  conservative  in  the  usual  sense  because  it  can  still  deadlock.  Our 
approach  is  conservative  in  thesensethat  it  does  not  need  to  abort  any  transac¬ 
tions  for  concurrency  control  reasons  and  also  because  it  tries  to  avoid  any  possi¬ 
ble  missteps  in  its  approach  to  scheduling. 

In  theOOL  scheduler,  we  lock  and  schedule  operations  as  we  normally  would, 
except  we  cannot  delay  low  write  operations  to  ensure  correct  read-down  opera¬ 
tions.  I  n  OOL  we  give  up  on  the  high  transaction  as  soon  as  we  detect  a  conflict 
with  a  low  write  operation.  We  can  do  better  than  this  by  trying  to  save  the  high 
transaction  instead  of  aborting  it.  In  the  conservative  orange  locking  approach, 


we  will  use  the  orange  locks  to  identify  a  current  low  transaction  that  we  can 
safely  read  from,  thus  we  do  not  havetogiveup  if  a  low  transaction  has  a  conflict 
with  a  read-down.  To  do  this,  we  may  have  to  resubmit  some  read-down  opera¬ 
tions  that  were  invalidated  by  low  transactions.  In  fact,  we  can  sometimes  do 
even  better  than  rereading  invalidated  read-downs.  If  we  override  a  read-down 
lock  into  an  orange  lock  before  we  schedule  the  associated  read-down  operation, 
we  can  delay  that  read  operation  until  we  have  identified  the  proper  low  transac¬ 
tion  to  read  from.  We  will  avoid  performing  an  invalid  read  in  the  first  place. 

We  continue  with  some  data  structure  definitions.  We  will  unavoidably  use 
some  terms  before  they  are  defined;  we  ask  the  reader  to  trust  that  all  meanings 
will  be  resolved  as  quickly  as  possible. 

5. 7  Local  Workspace 

E  ach  transacti  on  has  a  I  ocal  workspace  that  i  s  used  to  hoi  d  the  val  ues  of  data 
items  the  transacti  on  needs  to  read-down.  The  local  workspace  is  used  in  the 
same  way  as  in  optimistic  orange  locking;  any  read-downs  during  processing  are 
performed  from  the  transacti  on's  local  workspace.  In  conservative  orange  locking, 
each  read-down  data  item  in  the  local  workspace  can  be  marked  read  or  unread. 
These  markers  are  used  to  determine  when  a  transaction  has  reached  its  home- 
free  point.  Since  a  high  transaction  does  not  give  up  when  it  finds  one  of  its  read- 
down  operations  has  been  invalidated,  the  transacti  on  must  know  which  data 
items  to  reread  or  delay  on  in  order  to  get  a  valid  view  of  the  database. 

5.2  Read-Down  Queue 

The  scheduler  associates  every  transaction  with  a  transaction-specific  queue 
Qj,  called  a  read-down  queue.  Whenever  a  high  transaction  Tj  must  repeat  or  de¬ 
fer  one  of  its  reads,  it  does  so  in  order  to  read  from  a  currently  active  low  transac¬ 
tion  Tj.  To  do  this,  the  scheduler  places  transaction  Tj  on  the  low  transaction  T,'s 
read-down  queue  to  wait  for  Tj  to  write  the  necessary  value.  Management  of  the 
read-down  queues  is  done  by  the  scheduler.  A  low  transaction  Tj  is  not  even 
aware  of  the  existence  of  its  corresponding  read-down  queue  Qj. 

Along  with  low  transaction  Tj' s  read-down  queue,  the  scheduler  keeps  a  list  Wj 
of  values  written  by  the  corresponding  transacti  on.  For  efficiency,  this  list  Wj  may 
be  incorporated  into  the  database  system's  cache  and  recovery  log,  depending  on 
their  implementation.  When  low  transaction  Tj  commits,  the  scheduler  services 
the  reads  requested  by  any  high  transaction  Tj  that  was  placed  on  T/'s  read-down 
queue.  The  values  returned  aretaken  from  list  Wj.  (To  preserve  recoverability, 
cascadelessness,  and  strictness,  the  scheduler  should  not  make  orange  locked 
data  items  in  Wj  availablefor  reading  via  Q;-  until  transaction  Tj  has  committed.) 

5.3  Conservative  Orange  Locks:  Overriding  Read  Locks  for  Read-Downs 

The  heart  of  our  conservative  approach  is  the  way  we  use  orange  locks.  Instead 
of  passively  marking  data  items,  our  orange  locks  actively  affect  the  individual 
scheduling  of  reads  and  writes.  Whenever  a  low  transaction  Tj  needs  to  obtain  a 
write  lock  on  a  data  itemxthat  is  being  read  by  a  high  transaction  T,-,  the  sched¬ 
uler  tries1  to  overri de the  high  transaction  Tj' s  read-down  ofx.  On  benalf  of  trans- 


action  Tj,  the  scheduler  converts  7Ys  read  lock  to  an  orange  lock  on  data  item  x. 
Whenever  a  data  item  x  is  orange  locked  on  behalf  of  transaction  Tj,  data  itemx 
in  Tj' s  local  workspace  is  also  marked  unread  by  the  scheduler.  Even  if  data  item 
x  had  previously  been  read  it  is  still  marked  unread.  A  high  transaction  Tj  that 
has  its  read  lock  converted  to  an  orange  lock  is  placed  on  the  appropriate  read- 
down  queue  to  wait  for  the  overriding  low  transaction  7/  to  complete.  At  the  same 
time,  all  of  the  read-down  data  items  in  7/ 's  write  set  are  also  orange  locked  and 
thus  marked  unread.  At  this  point  we  say  that  transaction  Tj  is  orange  locked 
into  transact!  on  Tj.  If  7/  commits  then  Tj  will  read-down  from  transaction  Tj  every 
data  item  in  thewriteset  of  transaction  Tj  that  Tj  reads.  If  this  happens  then  the 
override  is  considered  to  have  occurred.  If  instead  transaction  Tj  aborts,  then  all 
of  the  orange  locks  that  were  associated  with  it  must  be  reset  to  read  locks  (the 
affected  data  items  will  all  still  be  unread)  and  transaction  Tj  must  continue  to 
try  to  reach  its  read-down  point.  If  another  low  transaction  7^  tries  to  write  lock 
data  itemx  and  high  transaction  Tj  already  holds  an  orange  lock  on  xthen  the 
original  orange  lock  is  retained  but  the  low  transaction  7^  gets  its  write  lock  and 
continues.  We  state  this  formally  as  the  orange  locking  rule. 

Definition  14.  We  denote  the  read  set  and  writeset  of  a  transaction  Tj  as  Rj  and  Wj 
respectively.  We  also  define  the  read-down  set  of  transaction  Tj  asthesetE,-  of  all 
Tj's  read-down  data  items  and  we  also  define  the  orange-1  ocked  set  Ojj  as  the  set  of 
all  read-down  data  items  that  Tj  reads  down  from  transaction  Tj  via  an  orange 
lock.  If  transaction  Tj  reads x  down  and  transaction  Tj  converts  Tj's  read  lock  on  x 
toan  orange  lock  then  0/y=E/n  Wj.  Iftransaction  Tj  readsxdown  and  its  read  lock 
is  not  converted  but  x  is  in  Wj  then  Ojj  is  empty.  We  will  refer  to  this  condition  as 
the  conservative  orange  locking  rule,  that  is  if  data  item  x  is  in  E,-n  Wj.  then 
Ojj=  E/n  Wj  or  0/y=  0  . 

5.4  The  Conservative  Orange  Locking  Algorithm 

Now  that  we  havea  clear  definition  of  the  override  operation,  it  is  possibleto 
talk  about  how  orange  locking  is  used  in  the  algorithm.  We  give  the  steps  to  be 
followed  by  a  transaction  7/  and  by  the  scheduler  in  serializing  7/ 's  operations. 

(1)  Transaction  7/  declares  its  read-down  set  E/  and  its  writeset  Wj. 

(2)  The  scheduler  marks  all  of  Tj's  local  workspace  unread  and  sets  Qj,  its  read- 
down  queue,  to  empty. 

(3)  While  some  read-down  data  item  in  its  local  workspace  is  still  marked  un¬ 
read,  transaction  Tj  submits  read-down  operations  for  those  unread  data  items. 
If  the  read-down  data  item  isread  locked  it  is  read  from  the  database  and  marked 
read  in  the  local  workspace.  Otherwise  the  data  item  must  be  orange  locked  and 
the  transaction  reads,  via  the  scheduler's  list  Wj,  from  the  committed  transaction 
Tj  whose  write  operation  required  conversion  of  7,'s  read  lock  into  an  orange  lock. 
When  this  step  completes,  transaction  Tj  has  reached  its  home-free  point. 

(4)  Transaction  Tj  now  releases  the  locks  on  its  read-down  data  items.  The  read- 
down  locks  can  be  released  together  in  a  single  operation.  Alternatively,  if  read- 


1.  The  read  lock  may  be  released  before  it  is  overridden. 


down  locks  are  not  released  together  and  some  low  transaction  Tj  requests  a 
write  lock  after  Tj  has  reached  its  home-free  point  but  before  the  scheduler  has 
released  all  of  T;'s  read-down  locks,  the  scheduler  simply  grants  the  write  lock 
and  schedules  the  write  before  releasing  the  rest  of  T,'s  locks. 

(5)  Transaction  Tj  now  performs  the  rest  of  its  processing  using  conventional 
strict  two-phase  locking  on  data  items  within  its  own  security  class.  If  transac¬ 
tion  Tj  needs  to  perform  a  write  operation  on  data  item  x  at  the  same  time  anoth¬ 
er  transaction  Tj  needs  to  read-down  x,  then  Tj  will  override  Ty's  read-down  by 
converting  Tj' s  read-lock  to  an  orange  lock. 

(6)  When  transaction  Tj  commits,  all  of  the  high  transactions  that  arewaitingfor 

Tj  on  the  scheduler's  queueQ/  are  all  owed  to  read  from  Tjt  via  the  scheduler's  list 
Wj.  At  this  point  transaction  Tj  will  have  succeeded  in  overriding  the  reads  of 
those  higher  transactions,  thus  requiring  them  to  read  from  list  Wj.  □ 

A  COL  scheduler  avoids  starvation1  because  it  selects  a  specific  active  low 
transaction  for  a  high  transaction  to  read  from,  or  it  schedules  the  high  transac¬ 
tion  to  read  from  the  database  itself  via  valid  read-downs.  It  achieves  this  at  the 
expense  of  complexity  of  mechanism.  Note  that  by  waiting  until  the  selected  low 
transaction  completes,  weincur  less  delay  than  our  intuition  would  suggest,  since 
we  would  have  had  to  wait  almost  as  long  for  the  selected  low  transaction  if  it  had 
already  held  the  lock. 

The  serialization  order  established  by  a  COL  scheduler  is  determined  by  the 
home-free  points  between  security  classes  and  by  the  lock  points  within  the  same 
security  class.  The  home-free  point  of  a  transaction  must  come  either  before  or  af¬ 
ter  the  lock  point  of  every  conflicting  transaction.  By  holding  its  read-down  locks 
until  its  home-free  point,  conservative  orange  locking  becomes  a  four-phase  proto¬ 
col.  There  is  a  growing  and  a  shrinking  phase  for  read-downs  and  then  a  growing 
and  a  shrinking  phase  for  intra-class  reading  and  writing. 

6.  Reset  Orange  Locking  (ROL) 

I  ntuiti  vely,  the  conservative  orange  locking  rule  may  seem  to  be  too  strong.  We 
would  I  ike  to  do  something  less  than  orange  lock  the  entire  intersection  of  a 
transaction's  read-down  set  and  the  corresponding  update  transaction's  write  set. 
Fortunately,  we  can  do  better  than  the  conservative  orange  locking  rule,  if  weare 
willing  to  return  to  the  possibility  of  infinite  overtaking  or  starvation.  We  can  do 
this  while  still  avoiding  the  need  to  abort  any  high  transactions  that  have  had 
read-downs  invalidated  by  low  write  operations. 

In  the  reset  orange  locking  algorithm,  we  use  the  same  definitions.  Again  the 
local  workspace  only  holds  the  values  the  transaction  needs  to  read  down.  In  the 
ROL  algorithm,  values  to  be  written  arenot  held  in  a  list  Wj  by  the  scheduler  and 
there  is  no  read-down  queueQ/  for  a  transaction.  Instead,  we  can  let  transactions 
read  down  directly  from  the  database. 


1.  An  exception  to  this  is  the  pathological  case  of  infinite  overtaking  by  transactions  that  abort 
and  restart  with  no  other  interleaved  transactions  committing  on  the  same  write  set. 


6. 1  Reset  Orange  Locks:  Resetting  Read  Locks  for  Read-Downs 

In  reset  orange  locking,  just  as  in  COL,  low  transactions  override  the  read 
down  locks  of  high  transactions.  Whenever  a  low  transaction  7/  needs  to  obtain  a 
write  lock  on  a  data  itemxthat  is  being  read  by  a  high  transaction  Ty,  the  sched¬ 
uler  tries  to  override  the  high  transaction  Ty's  read-down  ofx. 

In  reset  orange  locking,  the  effect  of  an  override  is  different  from  COL.  First, 
the  scheduler  sets  low  transaction  T/'s  write  lock  on  data  itemx  and  schedules 
transaction  T/'s  write  operation.  Then  the  scheduler  marks  data  item  x  in  trans¬ 
action  Ty's  local  workspace  as  unread.  Next,  the  scheduler  releases  high  transac¬ 
tion  Ty's  read  lock.  Eventually  transaction  Ty  requests  the  scheduler  to  set  it 
again,  by  asking  for  the  corresponding  read  operation.  The  result  of  this  attempt 
is  that  high  transaction  Ty's  read  request  is  queued  waiting  for  a  chance  to  read 
according  to  the  normal  rules  of  two-phase  locking  (e.g.  it  may  have  to  wait  for 
other  writes  besides  T/'s).  I  n  the  case  of  reset  orange  locking,  if  another  low  trans¬ 
action  T k  tries  to  write  lock  data  item  x  and  high  transaction  Ty  has  once  more  ob¬ 
tained  its  read  lock  on  data  itemx,  the  new  low  transaction  does  override  high 
transaction  Ty.  This  repeated  overriding  can  cause  starvation  and  transaction  Ty 
may  never  reach  its  home-free  point. 

Because  a  transaction  holds  all  its  read-down  locks  until  it  reaches  its  home- 
free  point  it  is  sure  to  detect  (via  resetting)  any  writes  that  could  potentially  in¬ 
validate  a  previous  or  pending  read  operation. 

6.2  The  Reset  Orange  Locking  Algorithm 

We  give  the  steps  foil  owed  by  a  transaction  T/  scheduled  by  ROL  and  by  the 
ROL  scheduler.  We  follow  the  same  style  of  exposition  to  allow  comparison  with 
COL. 

(1)  The  scheduler  marks  all  of  T;'s  local  workspace  unread. 

(2)  While  some  read-down  data  item  in  its  local  workspace  is  still  marked  un¬ 
read,  transaction  T/  submits  read-down  operations  for  those  unread  data  items. 
If  the  read-down  data  item  is  read  locked  it  is  read  from  the  database  and  marked 
read  in  the  local  workspace.  Otherwise  transaction  T/'s  read  request  is  queued 
waiting  for  a  chance  to  read  according  to  the  normal  rules  of  two-phase  locking. 
When  this  step  completes,  transaction  T/  has  reached  its  home-free  point. 

(3)  Transaction  T/  now  releases  the  locks  on  its  read-down  data  items.  The  read- 
down  locks  can  be  released  together  in  a  single  operation.  Alternatively,  if  read- 
down  locks  are  not  released  together  and  some  low  transaction  Ty  requests  a 
write  lock  after  T/  has  reached  its  home-free  point  but  before  the  scheduler  has 
released  all  of  T/'s  read-down  locks,  thescheduler  simply  grants  the  write  lock 
and  schedules  the  write  before  releasing  the  rest  of  T/'s  locks. 

(4)  Transaction  7/  now  performs  the  rest  of  its  processing  using  conventional 
strict  two-phase  locking  on  data  items  within  its  own  security  class.  If  transac¬ 
tion  Tj  needs  to  perform  a  write  operation  on  data  itemx  at  the  same  time  anoth¬ 
er  transaction  Ty  needs  to  read-down  x,  then  Tj  will  override  (via  thescheduler) 
Ty's  read-down  by  converting  Ty's  read-lock  to  a  queued  read-lock  request.  Trans- 


action  7/  commits  according  to  the  rules  of  conventional  strict  two-phase  locking. 
□ 

The  reset  orange  locking  algorithm  is  simpler  than  conservative  orange  lock¬ 
ing.  It  also  does  not  require  declaration  of  read-down  and  writesets.  I  n  return  for 
this  decrease  in  complexity,  we  now  have  the  possibility  of  delays  dueto  multiple 
overrides. 

7.  Correctness 

Our  proofs  depend  on  the  foil  owing  important  definition: 

Definition  15.  We  define  the  home-free  point  HFPj  of  transaction  7/  to  be  the  first 
unlock  operation  ruj[x]  performed  on  a  data  itemxthat  is  read  down  by  7/.  Wede- 
finethe  lock  point  LP,-  of  transaction  7/  to  bethefirst  unlock  operation  quj[y]  per¬ 
formed  on  a  data  item  yin  the  same  security  class  as  transaction  7/.  Intuitively, 
the  lock  point  of  7/  is  the  conventional  lock  point  associated  with  strict  two-phase 
locking,  as  we  use  it  within  a  security  class.  For  a  transaction  that  does  not  read 
down  we  consider  the  home-free  point  to  be  the  lock  point.  □ 

We  will  now  show  the  correctness  of  ROL.  I  nstead  of  the  usual  graph  theoretic 
proof,  we  argue  directly  towards  the  definition  of  conflict  serial izabi I ity. 

Given  any  history  H  produced  by  an  ROL  scheduler,  construct  from  H  a  serial 
history  Hs  as  follows:  take  the  committed  projection  of  H  and  for  every  pair  of 
transactions  ( 7/ ,  Tj)  in  C(H),  if 

1.  the  security  class  of  transaction  Tj  is  the  same  as  the  security  class  of 
transaction  Tj,  that  is,  7  (Tj)  =  X  (Tj),  then  put  the  transactions  intoHs  in  the 
order  that  their  lock  points  appear  in  C(H),  or 

2.  X  (Tj)<X(Tj)  or  vice  versa,  then  put  the  transactions  in  Hs  in  the  order  that 
the  home-free  point  of  the  high  transaction  appears  with  respect  to  the  low 
transaction's  lock  point  in  C(H),  or 

3.  some  transaction  is  pairwise  incomparable  to  every  other  transaction  in 
C(H)-,  put  each  such  transaction  at  the  end  of  Hs. 

The  serial  history  Hs  is  defined  over  the  same  set  of  transactions  and  has  the 
same  set  of  operations  as  C(H).  We  show  that  the  committed  projection  C(H)  or¬ 
ders  pai  rs  of  confli  cti  ng  operations  the  same  as  seri  al  hi  story  Hs  by  construed  ng  a 
chain  of  equivalent  histories  starting  from  C(H)  and  ending  with  Hs. 

By  the  definition  of  conflicting  operation  and  conflict  equivalence,  we  can  swap 
two  adjacent  nonconflicting  operations  in  a  history  and  the  result  will  be  equiva¬ 
lent  to  the  original  history.  Thus,  if  the  conflicting  operations  in  C(H)  and  Hs  are 
already  in  the  same  order  we  can  transform  C(H)  into  Hs  via  a  finite  number  of 
equivalence  preserving  swaps. 

To  show  that  all  pairs  of  conflicting  operations  are  already  in  the  same  order, 
we  consider  three  cases: 


Case  X  (Tj)  =  X  (T j)\  Only  operations  on  data  items  at  the  same  security  class 
conflict,  all  other  operations  must  be  read  downs.  By  the  strict  two-phase  locking 
of  step  (4)  we  know  that,  for  any  pair  of  conflicting  operations  pj[x],  qj[x],  either 

(1)C(H)=  a i  Pj[x]a2L  P/0C3  qj[x]a4  and 

(2  )H  s=  0C5  Pi[x]  otg  L  Pj(i7  qj[x]a8 

or  vice  versa,  depending  on  which  lock  point  comes  first  in  C(H).  Thus  all  pairs 
of  conflicting  operations  from  transactions  in  the  same  security  class  are  ordered 
the  same  in  C(H)  and  Hs.  □ 

CaseXfTj)  <X(Tj):  Definition  9  tel  I  s  us  that  we  can  only  have  conflicting  pairs 
of  theform  Wj[x],  rj[x],  in  either  order.  Suppose  we  have  committed  projection 

(3)  C(H)=  a  ry/xjp  Wj[x] y 

for  some  pai  r  of  operations  Wj[x],  rj[x].  By  steps  (2),  (3),  and  (4)  of  the  algo¬ 
rithm,  the  committed  projection  must  be 

(4)  C(H)=  a  r/xjfo  FIFPfi2Wj[x]y1L  P/y2 

We  know  that  every  other  pair  of  operations  Wj[y],  rj[y]  in  C(H)  must  also  be 
shuffled  such  that 

1.  rj[y]e  a  or  rj[y]ed,  by  the  definition  of  home-free  point,  and 

2.  Wj[x]<£  a  and  Wj[x]<£  8,  si  nee  transaction  Tj  will  be  in  its  step  2  or  step  3 

and  transaction  Tj  will  be  in  its  step  4. 

Thus  if  one  pair  of  conflicting  operations  Wj[x],  rj[x]  is  ordered  according  to 
equation  (3)  then  all  pairs  of  conflicting  operations  are  also  ordered  the  same 
way,  which  corresponds  to  the  application  of  serial  history  construction  rule  2: 
pi  ace  transaction  T:  before  transaction  Tj  in  Hs  because  Tj’s  home-free  point 
H FPj  i s  before  Tj '5  lock  poi  nt  L P;-  i n  C (FI). 

Suppose  that  the  committed  projection  has  some  pair  of  operations  Wj[x],  q[x] 
in  the  other  order,  that  is 

(5)  C(H)=  a  Wj[x]\ 3  rj[x]y 

By  steps  (2),  (3),  and  (4)  of  the  algorithm,  the  committed  projection  must  be 

(6)  aHhaWjMhLPjkrjMnHFPfe 

We  know  that  every  other  pair  of  operations  Wj[y],  rj[y]  in  C(H)  must  also  be 
shuffled  such  that 

1.  rj[y]<£  a  and  rj[y]<£  8 ,  si  nee  transaction  Tj  will  be  in  its  step  2  or  step  3  and 

transaction  Tj  will  be  in  its  step  4,  and 

2.  Wj[x]e  a  or  Wj[x]e  8,  by  the  definition  of  two-phase  locking. 

Thus  if  one  pair  of  conflicting  operations  Wj[x],  rj[x]  is  ordered  according  to 
equation  (5)  then  all  pairs  of  conflicting  operations  are  also  ordered  the  same  way, 
which  corresponds  to  the  application  of  serial  history  construction  rule  2:  place 
transaction  Tj  before  transaction  Tj  in  Hs  because  Tj ’s  lock  point  LP;-  is  before  Ty's 
home-free  point  HFPj  in  C(FI).  □ 


Case  X  (Tj)  >  X  (Tj)\  The  arguments  are  symmetri  c  to  the  precedi  ng  case.  □ 

The  correctness  proofs  for  COL  and  workspace-based  OOL  are  very  similar. 

For  simpleOOL  we  merely  notethat  any  potentially  nonserial izabletransactions 
are  missing  from  C(H)  and  use  the  proof  for  conventional  two-phase  locking  given 
in  [2]. 

8.  Security 

We  argue  informally  that  orange  locking  is  non  interfering.  We  need  to  do  this 
because  some  parts  of  the  algorithm  may  be  i  mpl emented  as  trusted  code.  We  can 
restrict  our  discussion  to  read-down  operations  because  they  are  the  only  parts  of 
the  algorithms  that  have  the  potential  to  affect  the  low  state  of  the  database  sys¬ 
tem  in  a  way  that  is  interfering.  We  assume  without  discussion  that  no  low  state 
variables  are  changed  explicitly  by  any  of  the  algorithms,  including  error  messag¬ 
es  that  might  report  a  data  item  as  being  locked.  I  nstead  we  are  concerned  with 
delays;  that  the  value  of  time  as  a  state  variable  can  be  made  to  change  according 
to  high  inputs  (read  down  requests)  to  our  algorithms.  In  all  three  algorithms,  if 
no  write  is  requested  while  a  read-down  lock  is  set,  there  is  no  delay  possible. 

In  COL  scheduling  we  must  set  the  low  transaction's  write  lock  immediately, 
before  we  invalidate  the  read-down  of  the  high  transaction.  Likewise,  the  sched¬ 
uling  of  the  write  operation  must  precede  the  orange  locking  action.  If  our  mecha¬ 
nism  for  recording  values  in  the  list  Wj  causes  a  perceptible  del  ay  in  returning  an 
acknowledgment  for  the  write,  then  COL  scheduling  could  have  a  problem.  How¬ 
ever,  the  valueof  a  write  is  usually  recorded  in  a  cache  or  recovery  log  or  both,  as 
part  of  the  normal  write  process.  If  not,  we  can  simply  make  the  write  operation 
always  put  the  value  in  Wj,  thus  it  becomes  a  constant  time  operation.  We  also 
need  to  make  the  action  of  placing  a  high  transaction  on  the  read-down  queue 
part  of  the  action  of  setting  a  write  lock. 

In  ROL  scheduling,  we  must  also  set  the  write  lock  immediately  and  schedule 
the  write  operation  right  away  so  as  to  make  the  write  a  constant  ti  me  operation. 
The  releaseand  resetting  of  the  high  transaction's  read  lock  will  not  interfere 
with  any  low  transaction.  Also,  in  ROL  we  do  not  have  to  deal  with  read-down 
queues  and  lists  of  writes,  so  it  is  easier  to  make  ROL  secure. 

OOL  scheduling  istrivially  non  interfering;  thescheduler  only  has  to  override 
read-down  locks.  Si  nee  the  orange  locked  transaction  will  be  aborted,  there  is  no 
problem  of  getting  correct  values  for  the  read  that  is  overridden. 

9.  Deadlocks 

Conventional  two-phase  locking  is  subject  to  deadlocks.  Two  or  more  transac¬ 
tions  can  obtain  exclusive  locks  (i.e.  write  locks)  that  the  others  are  waiting  for 
and  none  of  the  transactions  will  be  able  to  proceed.  This  is  because  the  two- 
phase  nature  of  the  algorithm  precludes  releasing  some  lock  and  resetting  it  lat¬ 
er.  Deadlocks  are  usually  resolved  by  restarting  one  of  the  transactions  involved 
in  the  deadlock. 


Orange  locking  has  the  same  potential  for  deadlocks,  within  transactions  at 
the  same  security  class,  for  the  same  reason.  Read-down  operations  across  securi¬ 
ty  classes  cannot  cause  deadlocks  at  lower  classes  because  read  locks  can  never 
delay  a  lower  transaction.  Transactions  that  read  down  via  orange  locking  can  be 
involved  in  deadlocks  because  they  may  also  interact  with  transactions  in  their 
own  security  class. 

10.  Application  to  the  Replicated  Arc  hitectuie 

Whileorange  locking  is  applicableto  kernelized  multilevel  database  systems 
we  are  interested  in  its  potential  for  use  in  concurrency  and  replica  control  for  the 
replicated  architecture  [4], 

Thefrontend-backend  architecture  with  full  replication  has  been  around  as  a 
concept  for  sometime  [15].  In  its  SINTRA  project,  the  Naval  Research  Laboratory 
is  currently  prototyping  several  frontend-backend  architectures  with  full  replica¬ 
tion.  What  will  be  called  in  this  paper  the  SINTRA  architecture  was  proposed  by 
Froscher  and  Meadows. 

The  SINTRA  architecture  uses  full  replication  to  provide  multilevel  security. 
There  is  an  untrusted  backend  database  system  for  each  security  class.  Data 
from  dominated  security  classes  is  replicated  in  each  backend  system.  Logically, 
the  user  is  allowed  to  read  down  and  write  at  the  same  class  but  physically  the 
frontend  reads  all  data  at  the  same  cl  ass  and  writes  at  the  same  class  and  up  into 
dominating  classes  to  maintain  the  replicas.  It  is  important  to  remember  that 
whilethe  replicated  architecture  uses  distributed  database  system  technology, 
the  replicated  approach  is  a  centralized  architecture.  These  techniques  may  be 
adapted  to  distributed  database  systems  but  not  without  careful  consideration  of 
additional  issues.  Figure  1  illustrates  the  basic  replicated  architecture,  for  the 
partial  order  of  Figure  2.  Notice  that  the  low  data  appears  at  all  backends,  left 
data  at  the  left  and  high  backends,  etc. 


Figure  1.  The  Replicated  Architecture 


high 


left  Cf  JD  ri9ht 

low  Xj 

Figure  2.  Partial  Order  for  Figure  1 

Several  defer  red -write  algorithms  have  been  developed  for  the  replicated  archi¬ 
tecture  [3,9,14].  Deferred-write  replica  control  algorithms  perform  updates  on 
one  replica  at  the  time  the  update  is  requested  and  defer  the  other  updates  until 
later.  I  n  contrast,  immediate-write  algorithms  update  all  replicas  simultaneously. 

I  mmediate-write  concurrency  control  algorithms  for  the  replicated  architec¬ 
ture  require  the  concurrency  control  mechanism  in  general  and  the  lock  table  in 
particular  to  reside  on  thefrontend.  Obtaininga  lock  on  data  itemxmust  lock  all 
replicas  of  x,  simultaneously,  by  a  global  lock  for  xacquired  on  thefrontend.  This 
is  because  the  write  operations  must  be  sent  to  the  backend  databases  simulta¬ 
neously.  Since  orange  locking  can  provide  this  kind  of  concurrency  control  with¬ 
out  introducing  signalling  channels,  it  is  suitablefor  immediate- write 
concurrency  control  in  the  replicated  architecture. 

11.  Conclusions 

Locking  is  the  preferred  mechanism  for  achieving  concurrency  control  in  prac¬ 
tical  systems.  Conventional  locking  introduces  signalling  channels.  We  have 
shown  three  different  ways  of  provided  channel-free  locking  for  concurrency  con¬ 
trol:  conservative  orange  locking,  reset  orange  locking,  and  optimistic  orange 
locking. 

The  structural  differences  between  these  three  algorithms  are  significant.  The 
COL  approach  avoids  the  possibility  of  starvation  in  the  theoretical  sense.  In  the 
practical  sense,  it  also  avoids  multiple  overrides  that  could  reduce  the  perfor¬ 
mance  of  ROL.  COL  is  structurally  more  complex  than  the  other  two  approaches, 
in  both  algorithm  and  data  structures.  The  ROL  approach  is  simpler  than  COL  in 
algorithm  and  data  structure.  It  can  suffer  from  multi  pie  overrides  of  its  read 
locks  but  it  does  not  need  to  abort  transactions  to  deal  with  overrides.  TheOOL 
approach  without  the  local  workspace  has  the  simplest  structure  of  all.  In  sys¬ 
tems  where  conflicts  are  few,  this  simplicity  will  give  it  the  best  performance  of 
the  three.  As  the  level  of  conflict  (number  of  conflicting  operations  per  transac¬ 
tion)  and  multiprogramming  (number  of  transactions  active  at  the  same  time)  in¬ 
creases,  determining  best  performance  among  the  three  approaches  becomes 
problematic. 

The  need  to  declare  read-down  sets  and  write  sets  in  COL  is  not  as  limiting  as 
it  first  seems.  The  declarations  prohibit  correct  scheduling  of  ad-hoc  transactions 
with  COL,  but  not  interactive  applications.  Many  interactive  DBS  applications 
are  supported  through  forms,  which  are  compatible  with  COL  scheduling. 


Some  trusted  code  may  be  necessary  to  implement  orange  locking.  The  lock  ta¬ 
bles  themselves  may  be  multilevel  objects  and  should  only  be  accessed  by  trusted 
code.  How  much  trusted  code  is  required  outside  the  lock  table  is  also  problemat¬ 
ic.  In  some  systems  it  may  be  possible  to  implement  the  lock  table  as  a  collection 
of  single-level  objects  and  the  lock  manager  as  a  collection  of  single-level  process¬ 
es. 


Future  work  should  investigate  performance  issues  in  greater  depth  and  look 
into  orange  locking  implementation  architectures  with  minimal  trusted  code.  Ex¬ 
tension  of  four-phase  locking  to  untrusted  systems,  with  an  eye  to  increasing  con¬ 
currency,  is  something  else  we  plan  to  investigate. 
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